<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html><html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" xmlns:m="http://www.w3.org/1998/Math/MathML" xmlns:pls="http://www.w3.org/2005/01/pronunciation-lexicon" xmlns:ssml="http://www.w3.org/2001/10/synthesis" xmlns:svg="http://www.w3.org/2000/svg">
  <head>
    <title>Ideas and tasks for contributing to Kawa</title>
    <link rel="stylesheet" type="text/css" href="docbook-epub.css"/>
    <link rel="stylesheet" type="text/css" href="kawa.css"/>
    <script src="kawa-ebook.js" type="text/javascript"/>
    <meta name="generator" content="DocBook XSL-NS Stylesheets V1.79.1"/>
    <link rel="prev" href="Overall-Index.xhtml" title="Index"/>
    <link rel="next" href="Installation.xhtml" title="Getting and installing Kawa"/>
  </head>
  <body>
    <header/>
    <section class="sect1" title="Ideas and tasks for contributing to Kawa" epub:type="subchapter" id="Ideas-and-tasks">
      <div class="titlepage">
        <div>
          <div>
            <h2 class="title" style="clear: both">Ideas and tasks for contributing to Kawa</h2>
          </div>
        </div>
      </div>
      <p>Kawa (like other Free Software projects) has no lack of tasks and projects
to work on.  Here are some ideas.
</p>
      <p>The ones marked <span class="emphasis"><em>(GSoC)</em></span> are probably most suitable for a Google
Summer of Code project, in being a reasonable size, self-contained, and not
depending on other tasks.
</p>
      <section class="sect2" title="Run interactive process in separate Java Virtual Machine:" epub:type="division" id="idm139667881027616">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title">Run interactive process in separate Java Virtual Machine:</h3>
            </div>
          </div>
        </div>
        <p><span class="emphasis"><em>(GSoC)</em></span>
</p>
        <p>When developing and testing it is useful for the REPL to support
hot-swapping (replacing functions on-the-fly) and debugging.
The main goal being able to smoothly reload changed modules
(files or functions), and have other modules not break.
Debugging (such as setting breakpoints) would not be a priority
for this project, but could be a follow-on project.
Skills: Should be experienced with Java, and interested in learning
about <a class="ulink" href="https://docs.oracle.com/javase/8/docs/technotes/guides/jvmti/index.html" target="_top">JVM TI</a> and similar low-level parts of the platform.
Difficulty: Challenging, but you can study
how <a class="ulink" href="https://en.wikipedia.org/wiki/Jshell" target="_top">Java-9’s new jshell</a>
uses the JVM TI.
</p>
      </section>
      <section class="sect2" title="Better dynamic reload" epub:type="division" id="idm139667881023360">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title">Better dynamic reload</h3>
            </div>
          </div>
        </div>
        <p><span class="emphasis"><em>(GSoC - this is related to the previous item)</em></span>
</p>
        <p>Kawa does a lot of optimizations and inlining.  This conflicts
with being able to “reload” a module into an already-running
interactive environment.
</p>
        <p>We could add an option to load a module in “reloadable” mode.
Kawa already patches an old function object (a <code class="literal">ModuleMethod</code>)
so existing references to the function get automatically updated.
However, there are problems if the “signature” of the function
changes - for example if the return type (declared or inferred)
becomes more general.  In those cases the best thing is to
re-compile any code that depends on the modified function.
</p>
        <p>Reloading a module that defines a class is even trickier,
at least if there are existing instances that should
work as the updated class.  We can handle the special case
where only method bodies change: In reloadable mode, each
method body is compiled to a separate function, the
actual body indirects to the function.  We must also
recognize when compiling a new version of the same
class, which requires a textual comparison between the
old and new versions, or a structural comparison
between the old class and the new code.
</p>
        <p>When it comes to top-level variables, an issue is when
to re-evaluate the initializing expression.  It is reasonable
to do so if and only if the expression is modified, which
again requires a textual comparison.
</p>
      </section>
      <section class="sect2" title="Easier Access to Native Libraries using JNA/JNR" epub:type="division" id="idm139667881017520">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title">Easier Access to Native Libraries using JNA/JNR</h3>
            </div>
          </div>
        </div>
        <p><span class="emphasis"><em>(GSoC)</em></span>
</p>
        <p>The traditional way to access native (C/C++) functions is using JNI,
but it’s very awkward.
JNA and <a class="ulink" href="https://github.com/jnr" target="_top">JNR</a> are <a class="ulink" href="http://www.oracle.com/technetwork/java/jvmls2013nutter-2013526.pdf" target="_top">much easier to use</a>.
This project would design and implement an easy-to-use Kawa wrapper for
for JNR.  You should study existing JNR wrappers, such as that for JRuby.
Difficulty: Medium.  Need to study existing wrappers and "foreign
function interfaces" (in multiple languages) and design one suitable for Kawa.
Some Scheme (Kawa) experience would be helpful.  
</p>
      </section>
      <section class="sect2" title="Types for units" epub:type="division" id="idm139667881013328">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title">Types for units</h3>
            </div>
          </div>
        </div>
        <p><span class="emphasis"><em>(GSoC)</em></span>
</p>
        <p>Kawa supports units (such as <code class="literal">cm^2</code> for square centimeters)
and <a class="link" href="Quantities.xhtml" title="Quantities and Units">quantities</a> (such as <code class="literal">4cm^2</code>).
We would like to integrate these into the type system, both
for performance and compile-time type checking.
</p>
        <p>For syntax we can use a pseudo-parameterized type <code class="literal">quantity</code>.  For example:
</p>
        <pre class="screen">(define a1 ::quantity[cm^2] 4cm^2)
(* 2.0 a1) ;; ⇒ 8cm^2
(+ 2.0 a1) ;; <span class="emphasis"><em>compile-time error</em></span>
</pre>
        <p>The run-time type of the variable <code class="literal">a1</code> should be
a primitive <code class="literal">double</code>, without object allocation.
Of course when <code class="literal">a1</code> is converted to an object, we
create a <code class="literal">Quantity</code>, not a <code class="literal">Double</code>.
We can build on Kawa’s existing framework for
non-standard primitive types such as <code class="literal">character</code> and <code class="literal">ulong</code>.
Skills: Need good Java experience, and somewhat familiar with the
Java Virtual Machine.
You will need to become comfortable reading &lt;code&gt;javap&lt;/code&gt; output.
Difficulty: Modest.
</p>
      </section>
      <section class="sect2" title="Compiler should use class-file reading instead of reflection" epub:type="division" id="idm139667881003824">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title">Compiler should use class-file reading instead of reflection</h3>
            </div>
          </div>
        </div>
        <p>The Kawa compiler currently uses reflection to determine properties
(such as exported function definitions) from referenced classes.
It would be better to read class files.
This should not be too difficult, since the <code class="literal">gnu.bytecode</code> library
abstracts over class information read by reflection or class reading.
</p>
      </section>
      <section class="sect2" title="Mutually dependent Java and Scheme modules" epub:type="division" id="idm139667881001568">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title">Mutually dependent Java and Scheme modules</h3>
            </div>
          </div>
        </div>
        <p><span class="emphasis"><em>(GSoC - maybe)</em></span>
</p>
        <p>We’d like a command for compiling a list of Java and Scheme
source files that may have mutual dependencies.  A good way
to do this is to hook into <code class="literal">javac</code>, which is quite extensible
and pluggable.
</p>
        <p>One could do something like:
</p>
        <div class="orderedlist" epub:type="list">
          <ol class="orderedlist" type="1">
            <li class="listitem" epub:type="list-item">
              <p>Read the “header" of each Kawa source file, to determine the
name of the generated main class.
</p>
            </li>
            <li class="listitem" epub:type="list-item">
              <p>Enter these class names into the javac tables as “uncompleted”
classes.
</p>
            </li>
            <li class="listitem" epub:type="list-item">
              <p>Start compiling the Java files.  When this requires the members
of the Kawa classes, switch to the Kawa files.  From javac,
treat these as pre-compiled .class files.  I.e. we treat the Kawa
compiler as a black box that produces Symbols in the same way as
reading class files.  At this point we should only need the
initial “scan” phase on Kawa.
</p>
            </li>
            <li class="listitem" epub:type="list-item">
              <p>If necessary, finish compiling remaining Kawa files.
</p>
            </li>
          </ol>
        </div>
        <p>This approach may not immediately provide as robust mixed-language
support as is ideal, but it is more amenable to incremental improvement
than a standalone stub-generator.
</p>
        <p>This project is good if you know or want to learn how <code class="literal">javac</code> works.
</p>
      </section>
      <section class="sect2" title="Use Java-7 MethodHandles and invokedynamic" epub:type="division" id="idm139667880993680">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title">Use Java-7 MethodHandles and invokedynamic</h3>
            </div>
          </div>
        </div>
        <p>Java 7 supports MethodHandles which are meant to provide better
performance (ultimately) for dynamic languages.
See <a class="ulink" href="http://jcp.org/en/jsr/detail?id=292" target="_top">JSR 292</a>
and the <a class="ulink" href="http://openjdk.java.net/projects/mlvm/" target="_top">Da Vinci Machine Project</a>.
Kawa makes limited use of MethodHandles, and no use of invokedynamic.
There is more to be done.  For example, we
can start by optimizing arithmetic when the types are unknown
at compile-time.  They could make implementing
generic functions (multimethods) more efficient.
At some point we want to compile lambdas in the same way
as Java 8 does. This can potentially
be more efficient than Kawa’s current mechanism.
</p>
        <p>Remi Forax’s <a class="ulink" href="https://github.com/forax/vmboiler" target="_top">vmboiler</a> is
a small library on top of ASM that generates optimistically typed bytecodes.
It could be useful for ideas.
</p>
        <span id="task-parameterized-types"/>
      </section>
      <section class="sect2" title="Parameterized types" epub:type="division" id="idm139667880988112">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title">Parameterized types</h3>
            </div>
          </div>
        </div>
        <p><span class="emphasis"><em>(GSoC)</em></span>
</p>
        <p>Kawa has some limited support for parameterized types, but
it’s not used much.  Improve type inferencing.
Support definition of parameterized classes.
Better use of parameterized types for sequence class.
Support wildcards.  
(It might be better to have wild-carding be associated with
declarations, as in Scala or <a class="ulink" href="http://openjdk.java.net/jeps/300" target="_top">proposed for Java</a>, rather than uses.)
See also <a class="ulink" href="http://openjdk.java.net/jeps/8043488" target="_top">http://openjdk.java.net/jeps/8043488</a>.
</p>
      </section>
      <section class="sect2" title="Optimized function types and values using MethodHandles" epub:type="division" id="idm139667880983728">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title">Optimized function types and values using MethodHandles</h3>
            </div>
          </div>
        </div>
        <p><span class="emphasis"><em>(GSoC)</em></span>
</p>
        <p>Kawa doesn’t have true function types: Parameter and result types
are only handled for “known” functions.  The general case with
optional and keyword parameter is complicated, but simple
fixed-arity procedure types would be very useful.
</p>
        <p>The following syntax is suggested:
</p>
        <pre class="screen">procedure[(<em class="replaceable"><code>T1</code></em> .. <em class="replaceable"><code>Tn</code></em>) <em class="replaceable"><code>Tr</code></em>]
</pre>
        <p><em class="replaceable"><code>T1</code></em> through <em class="replaceable"><code>T1</code></em> are types of the parameters, and
<em class="replaceable"><code>Tr</code></em> is the type of the result.
For example: <code class="literal">procedure[(vector int) string]</code>.
We call this a typed-procedure type (in contrast to plain <code class="literal">procedure</code>).
</p>
        <p>If a value has a typed-procedure type then its run-time representation
is a just a <code class="literal">MethodHandle</code>.  If such a procedure is called,
the generated bytecode is to just call its <code class="literal">invokeExact</code> method.
The argument expressions are converted (and type-checked) the same
way as if we were calling a statically-known procedure.
</p>
        <p>Note that passing an <code class="literal">int</code> argument
of to <code class="literal">procedure[(vector int) string]</code> value does <span class="emphasis"><em>not</em></span>
require allocating an object to “box” the <code class="literal">int</code>;
we can pass a plain <code class="literal">int</code> as-is.
Thus using typed-procedure types can lead to major speed-up.
For example the <code class="literal">lib-test.scm</code> should become much faster.
</p>
        <p>Converting a known procedure to a typed-procedure type is usually
just a matter of creating a <code class="literal">MethodHandle</code> that references the
method implementing the procedure.  Some glue code may be needed
if the types aren’t identical, or if the procedure is a closure.
</p>
        <p>Converting a type-procedure value <code class="literal">p</code> to generic value (such
as untyped <code class="literal">procedure</code> or <code class="literal">object</code>) can be though of as
wrapping it in a <code class="literal">lambda</code>:
</p>
        <pre class="screen">((lambda (arg1::vector arg2::int)::string (p arg1 arg2))
</pre>
        <p>Coercing a generic value or an untyped procedure to a typed-procedure would
need to generate a method whose signature matches the typed-procedure type,
and in the body of the method use a generic apply.
</p>
        <p>Coercing from one typed-procedure type to a different typed-procedure type
is a combination of the above techniques (as if converting first to object and
then to the target type), though some optimizations are worth doing.
</p>
        <p>Adding varargs support can be done later.
</p>
        <p>We need a fall-back mechanism for platforms (such as Android)
that don’t support <code class="literal">MethodHandle</code>s.  The easiest is to
just treat a typed-procedure type as plain <code class="literal">procedure</code> at run-time,
though we still want the compile-time type-checking,
</p>
      </section>
      <section class="sect2" title="Full continuations" epub:type="division" id="idm139667880964448">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title">Full continuations</h3>
            </div>
          </div>
        </div>
        <p><span class="emphasis"><em>Currently being worked on.</em></span>
</p>
        <p>Add support for full continuations, which is the major
feature missing for Kawa to qualify as a “true Scheme”.
One way to implement continuations is to add a add that converts
the abstract syntax tree to continuation-passing-style, and then
expand the existing full-tail-call support to manage a stack.
There are other ways to solve the problem.
This may benefit from <a class="link" href="Ideas-and-tasks.xhtml#task-faster-tailcalls">Faster tailcalls</a>.
</p>
      </section>
      <section class="sect2" title="Faster tailcalls" epub:type="division" id="idm139667880960688">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title">Faster tailcalls</h3>
            </div>
          </div>
        </div>
        <span id="task-faster-tailcalls"/>
        <p>Make <code class="literal">--full-tailcalls</code> run faster.
This may depend on (or incorporate)
<a class="link" href="Ideas-and-tasks.xhtml#task-TreeList-optimization">TreeList-optimization</a>. 
</p>
        <span id="task-TreeList-optimization"/>
      </section>
      <section class="sect2" title="TreeList-optimization" epub:type="division" id="idm139667880957200">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title">TreeList-optimization</h3>
            </div>
          </div>
        </div>
        <p>The <a class="ulink" href="http://www.gnu.org/software/kawa/api/gnu/lists/TreeList.html" target="_top">TreeList</a> class is a data structure for “flattened” trees.  It is used for
XML-style nodes, for multiple values, and for the full-tail-call API.
The basic concept is fine, but it could do with some re-thinking
to make make random-access indexing fast.  Also, support for updating
is insufficient.  (This needs someone into designing and hacking on
low-level data-structures, along with lots of profiling and testing.)
</p>
      </section>
      <section class="sect2" title="Asynchronous evaluation" epub:type="division" id="idm139667880954080">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title">Asynchronous evaluation</h3>
            </div>
          </div>
        </div>
        <p>C# recently added <code class="literal">asynch</code> and <code class="literal">await</code> keywords
for <a class="ulink" href="http://msdn.microsoft.com/en-us/vstudio/gg316360" target="_top">asynchronous programming</a>.  Kawa’s recently improved support for lazy programming
seems like a good framework for equivalent functionality:
Instead of an <code class="literal">asynch</code> method that returns a <code class="literal">Task&lt;T&gt;</code>,
the Kawa programmer would write a function that returns a <code class="literal">lazy[T]</code>.
This involves some design work, and modifying the compiler to
rewrite the function body as needed.
</p>
        <p>This is related to full continuations, as the re-writing is similar.
</p>
        <span id="task-REPL-improvements"/>
      </section>
      <section class="sect2" title="REPL console and other REPL improvement" epub:type="division" id="idm139667880948320">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title">REPL console and other REPL improvement</h3>
            </div>
          </div>
        </div>
        <p><span class="emphasis"><em>Currently being worked on.</em></span>
</p>
        <p>Improvements to the read-eval-print console.
In addition to a traditional Swing console,
it would be useful to support using a web browser as a remote terminal,
possibly using web-sockets.
(This allows “printing” HTML-expressions, which can be a useful way
to learn and experiment with web technologies.)
See <a class="ulink" href="http://per.bothner.com/blog/2007/ReplPane/" target="_top">here</a> for an article
on the existing Swing REPL, along with some to-do items.
Being able to hide and show different parts of the output might be nice.
Being able to link from error messages to source might be nice.
Better handling of redefinitions is discussed 
<a class="ulink" href="http://per.bothner.com/blog/2009/REPL-for-JavaFX/" target="_top">here in the context of JavaXF Script</a>; this is a general REPL issue, mostly independent of the GUI for it.
</p>
        <p>An interesting possibility is to use the <a class="ulink" href="http://ipython.org/" target="_top">IPython</a>
framework.  There are existing ports for Scala: either
<a class="ulink" href="https://github.com/mattpap/IScala" target="_top">IScala</a>
or <a class="ulink" href="https://github.com/Bridgewater/scala-notebook" target="_top">Scala Notebook</a>.
</p>
      </section>
      <section class="sect2" title="XQuery-3.0 functionality" epub:type="division" id="idm139667880941248">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title">XQuery-3.0 functionality</h3>
            </div>
          </div>
        </div>
        <p><span class="emphasis"><em>(GSoC, for some subset)</em></span>
</p>
        <p>It would be nice to update the XQuery (Qexo) support
to some subset of <a class="ulink" href="http://www.w3.org/TR/xquery-30/" target="_top">XQuery 3.0</a>.
</p>
      </section>
      <section class="sect2" title="XQuery-updates" epub:type="division" id="idm139667880938320">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title">XQuery-updates</h3>
            </div>
          </div>
        </div>
        <p>It would be nice to support <a class="ulink" href="http://www.w3.org/TR/xquery-update-10/" target="_top">XQuery updates</a>.  This depends on <a class="link" href="Ideas-and-tasks.xhtml#task-TreeList-optimization">TreeList-optimization</a>. 
</p>
        <span id="task-common-lisp"/>
      </section>
      <section class="sect2" title="Common Lisp support" epub:type="division" id="idm139667880934976">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title">Common Lisp support</h3>
            </div>
          </div>
        </div>
        <p>Kawa supports a small subset of the Common Lisp language, but it supports
a much larger subset of core Common Lisp concepts and data structures, some
designed with Common Lisp functionality in mind.  Examples include
packages, arrays, expanded function declarations, type specifications,
and format.  A lot could be done to improve the Common Lisp support
with modest effort.  Some Common Lisp features could also be useful
for Scheme: Documentation strings (or markup) as Java annotations,
better MOP-like introspection, and generic methods a la defmethod
(i.e. with multiple definition statements, possibly in separate files,
as opposed to the current make-procedure) all come to mind.
Being able to run some existing Common Lisp code bases with
at most modest changes should be the goal.
One such package to start with might be an
<a class="ulink" href="http://aperiodic.net/phil/archives/Geekery/notes-on-lisp-testing-frameworks.html" target="_top">existing test framework</a>, perhaps
<a class="ulink" href="http://common-lisp.net/project/bese/FiveAM.html" target="_top">FivaAM</a>.
Full Common Lisp compatibility is nice, but let’s walk before we can run.
</p>
      </section>
      <section class="sect2" title="JEmacs improvements" epub:type="division" id="idm139667880931136">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title">JEmacs improvements</h3>
            </div>
          </div>
        </div>
        <p><span class="emphasis"><em>(GSoC, for some subset)</em></span>
</p>
        <p>A lot of work is needed to make
<a class="ulink" href="http://jemacs.sourceforge.net/" target="_top">JEmacs</a> useful.
One could try to import a useful package and see what works and what fails.
Or one may look at basic editing primitives.
Enhancements may be needed to core Emacs Lisp language primitives
(enhancing <a class="link" href="Ideas-and-tasks.xhtml#task-common-lisp">Common Lisp support</a> may help),
or to the display engine.
</p>
        <p>Emacs now supports <a class="ulink" href="http://www.gnu.org/software/emacs/manual/html_node/elisp/Lexical-Binding.html" target="_top">lexical bindings</a> - we should do the same.
</p>
      </section>
      <section class="sect2" title="Improved IDE integration" epub:type="division" id="idm139667880926080">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title">Improved IDE integration</h3>
            </div>
          </div>
        </div>
        <p>There is some Kawa support for Eclipse (Schemeway), and possibly
other IDEs (NetBeans, IntelliJ).  But many improvements are
desirable.
<a class="link" href="Ideas-and-tasks.xhtml#task-REPL-improvements">REPL improvements</a> may be a component of this.
</p>
        <section class="sect3" title="Plugin for NetBeans IDE" epub:type="division" id="idm139667880923840">
          <div class="titlepage">
            <div>
              <div>
                <h4 class="title">Plugin for NetBeans IDE</h4>
              </div>
            </div>
          </div>
          <p>Kawa-Scheme support for the NetBeans IDE would be useful.
One could perhaps build on the Clojure plugin.
</p>
        </section>
        <section class="sect3" title="Plugin for Eclipse IDE" epub:type="division" id="idm139667880922256">
          <div class="titlepage">
            <div>
              <div>
                <h4 class="title">Plugin for Eclipse IDE</h4>
              </div>
            </div>
          </div>
          <p>Kawa-Scheme support for the Eclipse IDE would be useful.
Probably makes sense to
enhance <a class="ulink" href="http://sourceforge.net/projects/schemeway/" target="_top">SchemeWay</a>.
It may also make sense to build on
the <a class="ulink" href="http://www.eclipse.org/dltk/" target="_top">Dynamic Languages Toolkit</a>,
possibly making use of <a class="ulink" href="http://schemeide.sourceforge.net/" target="_top">Schemeide</a>,
though DLTk seems more oriented towards interpreted non-JVM-based languages.
</p>
        </section>
        <section class="sect3" title="Improve Emacs integration" epub:type="division" id="idm139667880918336">
          <div class="titlepage">
            <div>
              <div>
                <h4 class="title">Improve Emacs integration</h4>
              </div>
            </div>
          </div>
          <p><a class="ulink" href="http://en.wikipedia.org/wiki/SLIME" target="_top">SLIME</a> is an Emacs mode
that provides IDE-like functionality.  It supports Kawa.
</p>
          <p><a class="ulink" href="http://jdee.sourceforge.net/" target="_top">JDEE</a> is a Java development environment,
so might have better hooks to the JVM and Java debugging architecture.
</p>
          <p><a class="ulink" href="http://cedet.sourceforge.net/" target="_top">CEDET</a> is a more general
framework of development tools.
</p>
        </section>
        <section class="sect3" title="Implement javax.tools and code-range support in Kawa compiler" epub:type="division" id="idm139667880914080">
          <div class="titlepage">
            <div>
              <div>
                <h4 class="title">Implement <code class="literal">javax.tools</code> and code-range support in Kawa compiler</h4>
              </div>
            </div>
          </div>
          <p>Kawa currently records the line and column position of syntactic elements.
For an IDE it is desirable to have both start and end position of an element,
for example so it can put a squiggly line under an erroneous form.
</p>
        </section>
      </section>
      <section class="sect2" title="Hop-style web programming" epub:type="division" id="idm139667880911776">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title">Hop-style web programming</h3>
            </div>
          </div>
        </div>
        <p><a class="ulink" href="http://hop.inria.fr/" target="_top">Hop</a> is an interesting design
for integrating server-side and client-side programming using
a Scheme dialect.  These ideas seem like they would port
quite well to Kawa.
</p>
      </section>
      <section class="sect2" title="String localization" epub:type="division" id="idm139667880909600">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title">String localization</h3>
            </div>
          </div>
        </div>
        <p><span class="emphasis"><em>(GSoC)</em></span>
</p>
        <p>Support localization by extending the
<a class="ulink" href="http://srfi.schemers.org/srfi-109/srfi-109.html" target="_top">SRFI_109</a>
syntax, in the manner of (and compatible with)
<a class="ulink" href="http://www.gnu.org/software/gettext/" target="_top">GNU gettext</a>.
I.e. optionally specify a localization key (to use as an index
in the translation database); if there is no key specified,
default to using the literal parts of the string.
</p>
      </section>
      <section class="sect2" title="Data binding" epub:type="division" id="idm139667880905744">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title">Data binding</h3>
            </div>
          </div>
        </div>
        <p>Implement a “bind” mechanism similar to that
of <a class="ulink" href="http://docs.oracle.com/javafx/1.3/tutorials/core/dataBinding/" target="_top">JavaFX Script</a>.
The idea is that when you initialize a variable or field,
instead of initializing it to a fixed value, you bind it to
an expression depending on other variables.
We install “listeners” on those variables, so when those variables
change, we update the bound variable.
This feature is useful in many applications, but the initial
focus could be GUI programming and perhaps web programming.






</p>
      </section>
      <section class="sect2" title="Decimal arithmetic and repeated decimals" epub:type="division" id="idm139667880899984">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title">Decimal arithmetic and repeated decimals</h3>
            </div>
          </div>
        </div>
        <p><span class="emphasis"><em>(GSoC. Possibly a bit light for a full Summer project,
but can be extended or combined with other projects.)</em></span>
</p>
        <p>Exact decimal arithmetic is a variation of exact rational arithmetic,
but may be more user-friendly.  In particular, printing using
decimals is generally nicer than fractions.
It is also sometimes useful to specify an explicit scale,
so we can distinguish 0.2 from 0.20.
We can use the Java <code class="literal">BigDecimal</code> class, but run into problems
with division - for example <code class="literal">(/ 1.0 3.0)</code>.
We should implement a subclass of <code class="literal">RatNum</code> that generalizes
<code class="literal">BigDecimal</code> to also handle repeating decimals.
We need a lexical syntax for repeating decimals.
Possible ideas: <code class="literal">0._81_</code> or <code class="literal">0.#81</code>.
If a Scheme number literal is specified as exact and has either
a decimal point or an exponent (for example <code class="literal">#e1.25</code>), then it should
read as an exact decimal, not a fraction.
</p>
      </section>
      <section class="sect2" title="Optional strict typing along with an explicit dynamic type" epub:type="division" id="idm139667880894144">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title">Optional strict typing along with an explicit <code class="literal">dynamic</code> type</h3>
            </div>
          </div>
        </div>
        <p><span class="emphasis"><em>(GSoC)</em></span>
</p>
        <p>Kawa currently implements “optimistic” typing: The compiler only
complains if an expression has no values in common with the target type
- for example, if assigning a <code class="literal">string</code> expression to an <code class="literal">integer</code>
variable.
It would be interesting to experiment with a
<code class="literal">--strict-typing</code> option (which would never be the default):
Strict typing would only allow “widening” conversions - i.e.
that the expression type be a subtype of the target type.
For example it would complain if assigning a <code class="literal">number</code> to an <code class="literal">integer</code>
unless you used an explicit cast.
</p>
        <p>To make this easier to work with we’d make use
of the <a class="link" href="Standard-Types.xhtml#dynamic-type"><code class="literal">dynamic</code> type</a>, similar to
<a class="ulink" href="https://msdn.microsoft.com/en-us/library/dd264736.aspx" target="_top">what
<code class="literal">C#</code> does</a>: Any expression can be converted
to or from <code class="literal">dynamic</code> without the compiler complaining.
Similarly, if <code class="literal">x</code> is <code class="literal">dynamic</code> then <code class="literal">x:name</code>
is allowed by the compiler regardless of <code class="literal">name</code>, with all checking
being deferred to run-time.  If a variable is declared without a type,
it should default to <code class="literal">dynamic</code>.  The <code class="literal">dynamic</code> type
is represented in the VM as <code class="literal">object</code> but with an annotation
(like we do with <code class="literal">character</code>).
</p>
        <p>The type-checker might need some changes to better distinguish
implicit conversions from explicit casts.
</p>
      </section>
    </section>
    <footer>
      <div class="navfooter">
        <ul>
          <li>
            <b class="toc">
              <a href="Ideas-and-tasks.xhtml#idm139667881027616">Run interactive process in separate Java Virtual Machine:</a>
            </b>
          </li>
          <li>
            <b class="toc">
              <a href="Ideas-and-tasks.xhtml#idm139667881023360">Better dynamic reload</a>
            </b>
          </li>
          <li>
            <b class="toc">
              <a href="Ideas-and-tasks.xhtml#idm139667881017520">Easier Access to Native Libraries using JNA/JNR</a>
            </b>
          </li>
          <li>
            <b class="toc">
              <a href="Ideas-and-tasks.xhtml#idm139667881013328">Types for units</a>
            </b>
          </li>
          <li>
            <b class="toc">
              <a href="Ideas-and-tasks.xhtml#idm139667881003824">Compiler should use class-file reading instead of reflection</a>
            </b>
          </li>
          <li>
            <b class="toc">
              <a href="Ideas-and-tasks.xhtml#idm139667881001568">Mutually dependent Java and Scheme modules</a>
            </b>
          </li>
          <li>
            <b class="toc">
              <a href="Ideas-and-tasks.xhtml#idm139667880993680">Use Java-7 MethodHandles and invokedynamic</a>
            </b>
          </li>
          <li>
            <b class="toc">
              <a href="Ideas-and-tasks.xhtml#idm139667880988112">Parameterized types</a>
            </b>
          </li>
          <li>
            <b class="toc">
              <a href="Ideas-and-tasks.xhtml#idm139667880983728">Optimized function types and values using MethodHandles</a>
            </b>
          </li>
          <li>
            <b class="toc">
              <a href="Ideas-and-tasks.xhtml#idm139667880964448">Full continuations</a>
            </b>
          </li>
          <li>
            <b class="toc">
              <a href="Ideas-and-tasks.xhtml#idm139667880960688">Faster tailcalls</a>
            </b>
          </li>
          <li>
            <b class="toc">
              <a href="Ideas-and-tasks.xhtml#idm139667880957200">TreeList-optimization</a>
            </b>
          </li>
          <li>
            <b class="toc">
              <a href="Ideas-and-tasks.xhtml#idm139667880954080">Asynchronous evaluation</a>
            </b>
          </li>
          <li>
            <b class="toc">
              <a href="Ideas-and-tasks.xhtml#idm139667880948320">REPL console and other REPL improvement</a>
            </b>
          </li>
          <li>
            <b class="toc">
              <a href="Ideas-and-tasks.xhtml#idm139667880941248">XQuery-3.0 functionality</a>
            </b>
          </li>
          <li>
            <b class="toc">
              <a href="Ideas-and-tasks.xhtml#idm139667880938320">XQuery-updates</a>
            </b>
          </li>
          <li>
            <b class="toc">
              <a href="Ideas-and-tasks.xhtml#idm139667880934976">Common Lisp support</a>
            </b>
          </li>
          <li>
            <b class="toc">
              <a href="Ideas-and-tasks.xhtml#idm139667880931136">JEmacs improvements</a>
            </b>
          </li>
          <li>
            <b class="toc">
              <a href="Ideas-and-tasks.xhtml#idm139667880926080">Improved IDE integration</a>
            </b>
          </li>
          <li>
            <b class="toc">
              <a href="Ideas-and-tasks.xhtml#idm139667880911776">Hop-style web programming</a>
            </b>
          </li>
          <li>
            <b class="toc">
              <a href="Ideas-and-tasks.xhtml#idm139667880909600">String localization</a>
            </b>
          </li>
          <li>
            <b class="toc">
              <a href="Ideas-and-tasks.xhtml#idm139667880905744">Data binding</a>
            </b>
          </li>
          <li>
            <b class="toc">
              <a href="Ideas-and-tasks.xhtml#idm139667880899984">Decimal arithmetic and repeated decimals</a>
            </b>
          </li>
          <li>
            <b class="toc">
              <a href="Ideas-and-tasks.xhtml#idm139667880894144">Optional strict typing along with an explicit <code class="literal">dynamic</code> type</a>
            </b>
          </li>
        </ul>
        <p>
          Up: <a accesskey="u" href="Community.xhtml">The Kawa Community</a></p>
        <p>
        Previous: <a accesskey="p" href="Projects.xhtml">Projects using Kawa</a></p>
      </div>
    </footer>
  </body>
</html>
